home *** CD-ROM | disk | FTP | other *** search
/ Tech Arsenal 1 / Tech Arsenal (Arsenal Computer).ISO / tek-04 / love4th.zip / SEGMENT.DOC < prev    next >
Text File  |  1991-10-01  |  15KB  |  333 lines
  1. LOVE Forth addressing and segmentation
  2. --------------------------------------
  3.         Almost all languages have problems running on the 8086/88, but
  4. these problems for FORTH are especially severe. Most FORTH systems on
  5. this architecture are restricted to 64K of main memory for program and
  6. data, and are referred to as small memory models. This restricts the
  7. user and programs to a small amount of memory, but offers the highest
  8. possible execution speed.  32 bit FORTHS have been produced that offer
  9. a large address space, but performance has been severely degraded.  The
  10. segmentation approach taken in LOVE FORTH offers both a large memory
  11. size ( 320K ) and very fast execution speed.
  12.  
  13.         Rather than offer a large contiguous memory space, LOVE Forth
  14. has divided up the forth model by function.   There are separate
  15. segments for machine code, threaded addresses, data, stacks and
  16. dictionary headers.  As the source code is compiled it is parcelled
  17. into these five segments.  There is no execution time penalty over
  18. Forths with the small memory model.
  19.  
  20.         Note that this implementation is quite compatible with standard
  21. 16 bit models.  For example, @ (fetch) and !  (store) access the data
  22. segment (the vast majority of FORTH programs use @ and !  to access
  23. data).  Another example is that the assembler always puts its code into
  24. the code segment. The programmer need not worry that the code has been
  25. separated from the rest of the program.  Even though segmentation is
  26. provided for in a logical fashion, some compiler words must be
  27. implemented differently than in standard FORTH.
  28.  
  29.         There are numerous indirect benefits to this segmentation, over
  30. and above that of memory conservation.  Target systems can easily be
  31. saved without heads (the head segment is simply not written to disk).
  32. The segments can be compressed to provide small target systems.  And
  33. because machine code is separated from threads, it is actually possible
  34. to save space in the thread segment by re-coding some words in machine
  35. code.  (The thread segment always fills the fastest).  This gives
  36. simultaneously a speed and size advantage.
  37.  
  38.         Note that this conforms closely to the intended usage of the
  39. architecture of 8086/88 microprocessors.  The ususal programming battle
  40. with these processors is to overcome this limited architecture.
  41.  
  42. Here is a summary of the contents of each segment:
  43.  
  44. Segment         Description                                     Name
  45. =======         ===========                                     ====
  46.  
  47. CODE            Contains 8086 machine code                      CS:
  48.                 pointed to by CS register
  49.  
  50. THREAD          Contains threaded address lists generated by    TS:
  51.                 high level words.
  52.                 The code field address points here.
  53.                 pointed to by DS register
  54.  
  55. DATA            holds data from variables, alphanumeric strings, VS:
  56.                 and block buffers.
  57.                 pointed to by ES register
  58.  
  59. HEAD            holds the compile-time word headers, and         HS:
  60.                 vocabulary links.
  61.                 (segment value calculated when req'd)
  62.  
  63. STACK           holds the parameter, return and vocabulary       SS:
  64.                 stacks and local variables, if used.
  65.                 pointed to by SS register
  66.  
  67.         Each segment has a corresponding dictionary pointer, and a set
  68. of basic manipulation words such as CS:@ or HS:, .  Note that all the
  69. addresses within these segments are 16 bits.   The programmer must
  70. specify the segment to be operated upon by the type of operator used
  71. (eg. @, TS:@, CS:@ etc.)
  72.  
  73.         As MS-DOS tends to vary the position in RAM at which a program
  74. is loaded, each segment also has a word to return the actual position of
  75. the segment (GET:CS, GET:SS etc.).   The handy command MEM-MAP displays
  76. all the segments, and their respective dictionary pointers.
  77.  
  78.        In this documentation and elsewhere, addresses are abbreviated.
  79. For example TS:addr represents an address in the thread segment.
  80. Simply 'addr' refers to the the variable segment (most often used).
  81. Some names assume a segment, for example 'compilation address' is always
  82. in the thread segment, name field address is always in the head segment.
  83.  
  84. CODE SEGMENT
  85. ------------
  86.         This is the only segment that contains 8086/8088 machine code.
  87. Apart from the space taken by a few pointers used in CREATE DOES>
  88. words, this allows code to reach a full 64K.  The assembler places the
  89. definition body into the code segment automatically.
  90.  
  91.         This is always the lowest of the 5 segments.  Startup code in
  92. this segment, sets up the other segments.  This segment contains the
  93. MS-DOS "PSP" (program segment prefix) in the first 256 bytes, in
  94. version 1.28 and prior ones.   Use !!GET:PSP! in newer versions.
  95.  
  96. Basic operators:
  97.         CS:C@ CS:@ CS:! CS:C!  CS:,  CS:C,  CS:HERE
  98.  
  99.         These are analogous to the standard words: C@ @ ! C! , C, and
  100.         HERE, but operate on the code segment.
  101.  
  102.         'CODE operates like ' but returns the address of the executed
  103.         code extracted from the compilation address.   For example all :
  104.         words return the same value from 'CODE because they all call
  105.         the common code for nesting colon definitions.  It is thus most
  106.         useful with CODE words, where it returns the address of the
  107.         code loaded by the assembler.
  108.  
  109.         CS:DUMP is a utility that allows bytes to be dumped from this
  110.         segment.  ( CS:addr,  #bytes  --  )
  111.  
  112.         There are also some system 'variables' which are used, for
  113. example, at start-up before all the segments have been loaded or
  114. properly positioned.
  115.  
  116.         TOPSEG STACKSIZE TOPSEG  SEGPAK  LOVEF
  117.         CSEG   TSEG VSEG HSEG SSEG
  118.  
  119.         The current segment (position in RAM) is returned by:
  120.         GET:CS (8086 CS register)
  121.  
  122. THREAD SEGMENT
  123. --------------
  124.         Forth high-level (:) words are compiled into a sequence of 16
  125. bit addresses, called threads. This segment contains these threads,
  126. CONSTANT and LITERAL values, and pointers to data and code.  In the
  127. majority of applications this segment fills up the fastest.
  128.  
  129. Basic operators:
  130.         TS:@ TS:! TS:,  TS:HERE
  131.         Note that there are no single byte operators - all elements in
  132.         this segment are two bytes.
  133.  
  134.         EXECUTE      ( TS:addr  --  )
  135.         Accepts the code field address.
  136.  
  137.         TS:DUMP      ( TS:addr, #bytes --  )
  138.         Dumps bytes from the specified address.
  139.  
  140.         Many words with compile-time usage accept or return addresses in
  141.         this segment:
  142.  
  143.         '  [']   -FIND    (  --  TS:addr )
  144.  
  145.         FIND    ( VS:addr  --  VS:addr, 0    or    TS:addr, n  )
  146.  
  147.         Words created with the following return a thread segment address
  148.         at run-time:
  149.         CREATE: (alone)   or  CREATE: DOES:> ( pair)
  150.         The most often used words for creation are CREATE and
  151.         CREATE DOES> (pair).  See the Variable segment (below).
  152.  
  153.         In addition the following words add to this segment and have
  154.         functions as expected:
  155.         COMPILE   [COMPILE] wordname   LITERAL    DLITERAL
  156.  
  157.         See also the technical note on L.O.V.E. Forth compatibility for
  158.         examples of compile-time word usage.
  159.  
  160.         TS:BODY> TS:>BODY   ( TS: addr   --   TS: addr   )
  161.         are like >BODY  and  BODY> but operate on the thread segment
  162.         only.  (see discussion of 'Field access operators' below)
  163.  
  164.         >BODY     ( TS:addr  --   VS:addr  )
  165.         operates in LOVE Forth to accept a code field address of a
  166.         VARIABLE (or word created by CREATE) and return the data field
  167.         address.
  168.  
  169.         >LINK  >NAME  ( TS:addr  --  HS:addr  )
  170.         are used to access the dictionary header of the specified word.
  171.         If TS:addr is not a valid code field address, an error message
  172.         is displayed.
  173.  
  174.         NAME>  LINK>  ( HS:addr   --  TS:addr  )
  175.         are used to find the compilation address from the head address.
  176.  
  177.         FIND-1VOC  FIND-VOCS
  178.           ( addr, addr  --  TS:addr,true  or false)
  179.         are used by FIND - address of word to find (usually at
  180.         HERE) and vocab body input and cfa output (if found).
  181.  
  182.         GET:TS - returns current segment value (8086 DS register)
  183.  
  184. VARIABLE (DATA) SEGMENT
  185. -----------------------
  186.         This segment is accessed the most often by application programs.
  187. This contains the data for variables, alphanumeric strings compiled by
  188. ." and " , BLOCK buffers, text input buffer (TIB), PAD, HERE  and where
  189. space is allocated for programmer defined data structures.  Most
  190. standard Forth memory access words work relative to this segment.
  191.  
  192. Basic operators:
  193.         @ ! C@ C!  C, , D@ D! +! +C!  TYPE ALLOT
  194.         TOGGLE BMOVE CMOVE CMOVE> FILL
  195.         ENCLOSE EXPECT COUNT TYPE -TRAILING
  196.         CONVERT NUMBER  #>
  197.         HERE  PAD  WORD
  198.         BLOCK  LIMIT  FIRST  BUFFER +BUF R/W
  199.  
  200.         Various I/O words:
  201.         L->CRT N$ N$. 'STREAM
  202.  
  203.         TIB, HLD and other VARIABLEs all return addresses in VS:
  204.  
  205.         File name strings passed into DOS words:
  206.         <OPEN> OPEN <CREATE> FCREATE INQUIRE <CREATE-NEW> CREATE-NEW
  207.         DELETE RENAME CHDIR
  208.  
  209.         Other DOS words:
  210.         READ WRITE ENV-SRCH DIR-GET ASCIIZ. ASCIIZ"
  211.  
  212.         -words created by VARIABLE DVARIABLE CREATE
  213.         CREATE ... DOES>
  214.  
  215.         DUMP ( addr, #bytes-- ) Dumps the specified bytes.
  216.  
  217.         GET:VS - returns current segment value (8086 ES register)
  218.  
  219. HEAD SEGMENT
  220. ------------
  221.         The head segment is normally used during compilation only.  It
  222. contains the header part of a Forth word definition, including name,
  223. dictionary links and pointers to the locations of the word in other
  224. segements.   This segment may be discarded when creating a stand-alone
  225. application program.  Utilities such as WORDS and FORGET access this
  226. segment automatically.
  227.  
  228. Basic operators:
  229.         HS:@ HS:! HS:C@ HS:C!   HS:, HS:C,  TRAVERSE
  230.         N>LINK  L>NAME  LINK>  NAME>
  231.         .ID   LAST
  232.         HS:HERE returns the next available address in this segment.
  233.  
  234.         GET:HS - returns current head segment value (calculated)
  235.         Note TOGGLE does not act on HS: (often used to toggle header
  236.         bits)
  237. Note: the form of the head segment is subject to change in future 
  238.       versions by the authors without prior notice.
  239.  
  240. STACK SEGMENT
  241. -------------
  242.         This segment holds the Forth parameter, return, vocabulary and
  243. local variables stacks.  The operation of words on this segment is
  244. transparent to the programmer.  During development, allowing a full 64K
  245. to the stack segment means that system crashes due to stack overflow are
  246. minimized.
  247.         Basic operators: SS:@  SS:!     .S
  248.  
  249.         SP@  RP@  LP@  ( -- SS:addr )
  250.         These words return stack limits or current positions
  251.         S0
  252.         is a variable that contains the address of the bottom of stack
  253.  
  254.         SS:HERE
  255.         Is the dictonary pointer in this segment, but is currently
  256.         unused by any words in L.O.V.E. Forth and may be used by
  257.         the programmer if so desired.
  258.  
  259.         GET:SS - returns current segment value (8086 SS register)
  260.  
  261. Field Access Operators
  262. ======================
  263.         Every word in Forth has a number of parts or fields.  These
  264. include the name, link, code and parameter fields.  Field access
  265. operators are used to gain access to the various portions of forth
  266. words.   In L.O.V.E. Forth, as the parts of words are parcelled between
  267. segments, many of these operators accept an address in one segment and
  268. deliver an address in another.   Here is a summary of the standard
  269. field access operators and their functions in LOVE Forth.
  270.  
  271.         >BODY     ( TS:addr  --  addr  )
  272.         accepts a code field address of a VARIABLE (or word created by
  273.         CREATE) and returns the data field address (in VS:) .
  274.  
  275.         TS:>BODY TS:BODY>   ( TS: addr   --   TS: addr   )
  276.         are like >BODY  and  BODY> but operate on the thread segment
  277.         only.   Given the compilation address, TS:>BODY returns the
  278.         address of the first threaded address (of a : definition), the
  279.         data field of a CONSTANT, or the address pointer of a VARIABLE.
  280.         Note that there are thus two types of >BODY.  >BODY could be
  281.         rewritten:
  282.                 : >BODY TS:>BODY TS:@ ;
  283.  
  284.         >LINK  >NAME  ( TS:addr  --  HS:addr  )
  285.         are used to access the dictionary header of the specified word.
  286.         If TS:addr is not a valid compilation address, an error message
  287.         is displayed and execution is ABORTed.
  288.  
  289.         NAME> LINK>  ( HS:addr   --  TS:addr  )
  290.         are used to find the compilation address from the header
  291.         addresses name and link fields.
  292.  
  293.         N>LINK L>NAME ( HS:addr  --  HS:addr  )
  294.         are used to move between the name and link fields which are
  295.         both in the head segment.
  296.  
  297.         Note that there is no word BODY> to move from the VS: parameter
  298.         address of a VARIABLE or CREATEd word to the compilation
  299.         address.  This is not supported in L.O.V.E. Forth.
  300.  
  301. Long Operators
  302. ==============
  303.         LOVE Forth contains a set of basic operators which operate on
  304. any area of memory.  These words allow the specification of both the
  305. segment and address of the word to be operated upon.
  306.  
  307. Basic operators: @L !L C@L C!L  BMOVEL
  308.  
  309.         Some disk operators will operate on any segment:
  310.         READL WRITEL <READL> <WRITEL>
  311.         RWTSL EXEC
  312.  
  313.         ENV-SRCH ( string -- seg, addr, f     or     t )
  314.         returns both segment and address of DOS environment
  315.  
  316.         DUMPL ( seg,addr,#bytes -- )
  317.         Allows memory to be dumped relative to any segment.
  318.  
  319. Memory map
  320. ----------
  321.         The dictionary pointers move up as more is compiled.  Certain
  322. words only use certain segments (eg. a CONSTANT occupies only the thread
  323. and head segments).   When any of the dictionary pointers reaches within
  324. 400 bytes of the maximum available address a warning message is
  325. displayed 'GETTING CLOSE TO FULL'.
  326.  
  327.         The maximum available address in each segment is dependent on
  328. several things.  Virtual vocabularies are loaded in high memory, disk
  329. buffers are also here (in the VS: only - minimum of 2k bytes).  The
  330. current maximum addresses are always stored in the VARIABLE TOPS
  331. (contains one cell for each of CS:  TS: VS:  and HS:).  If the program
  332. is very large, it is best to remove any resident virtual vocabulary
  333. with FORGET-SYS.